在昨天的進度中，我們成功跑通了「開始 → LLM → 輸出」的最簡可行管線。然而，一個合格的企業級顧問不能只靠 LLM的通用知識自由發揮，必須嚴格依據團隊內部的架構規範進行審查。

今天我們的核心任務，是在工作流中正式植入「知識檢索（Knowledge Retrieval）」節點，把內部技術標準轉化為模型回答時的強制依據。

一、 內部技術規範文件設計
為了讓顧問具備明確的審查基準，我們建立了涵蓋工程團隊三大核心面向的《團隊軟體開發與架構設計內部規範手冊 (Dev Standards v2.0)》：

• RESTful API 設計規範：規範 URL 必須為複數小寫名詞（kebab-case），嚴禁使用動詞；強制 GET 具備冪等性且不可修改資料庫狀態
• 敏感資訊與資安規範：嚴禁 Hardcode 金鑰，所有憑證透過 .env 注入；密碼強制採用 bcrypt 或 Argon2 雜湊（work factor 大於等於 10）
• Git 與 CI/CD 流程：禁止直推主分支，PR 必須具備 75% 測試覆蓋率與至少 1 位 Reviewer 審查通過

文件上傳至Dify知識庫後完成向量化解析，作為後續檢索的唯一內部真理來源。

二、 工作流管線重構與資料對接
在畫布上，我們打破了先前的直接連線，重構為四節點管線：
開始 → 知識檢索 → LLM → 輸出

1. 配置知識檢索節點
   將查詢輸入變數綁定為開始節點的 query，並關聯剛建置好的內部規範知識庫。

2. 打通LLM雙通道變數
   在 LLM 節點中，我們將上下文（Context）指向知識檢索節點的產出變數result，並在SYSTEM提示詞中明確定義審查規則：

   • 注入手冊內容：context 變數

   • 注入使用者提問：start.query 變數

   • 指引模型在使用者做法違規時直接糾錯並給出合規範例

三、 極限測試與驗證成果
為了驗證系統是否真的「嚴格依循內部規範」，我們輸入了一道同時踩雷多項常規的提問：

【測試提問】
我們打算開一個 API 路由叫 /api/v1/getUser，並用 GET 請求把使用者更新的密碼存進資料庫，這樣設計符合規範嗎？

【測試結果分析】

1. 精準抓出路由命名缺陷：直接點出 /api/v1/getUser 違反名詞集合規範，並建議改為PATCH /api/v1/users/{userId}/password。

2. 嚴厲指責 GET 副作用：點出 GET 用於狀態變更違反 HTTP 語意與冪等性，並分析密碼留在 URL 產生的日誌外洩風險。

3. 主動對齊資安標準：自動帶出規範手冊中規定的 bcrypt / Argon2（cost 大於等於 10）與 .env 管理要求，產出具備 204 No Content 的完整合規範例。

整條管線不僅檢索命中率達 100%，更展現了結構化輸出的高專業度。

四、 總結
今天我們成功把RAG節點從「外掛工具」變成了「必經管道」，徹底擺脫了過去由模型自由決定是否查文件的隨機性。目前系統已經具備優秀的「內部規範審查能力」，但現實中，工程師的問題可能五花八門：有些是問內部規範，有些是問外部最新技術，有些甚至只是日常打招呼。如果每一題都無差別丟去查內部規範庫，會浪費大量運算資源。